Network service header (nsh) relaying of serviceability of a service function

ABSTRACT

At a service function node configured to perform at least one service function on a data flow that follows a service function path, degradation in performing the service function is detected. The service function node generates a status indicator for the degradation in performing the service function and inserts the status indicator into a peer detection packet. The peer detection packet encapsulates an inner packet with a header that indicates the service function path. The service function node forwards the peer detection packet to a neighboring service function node along the service function path.

TECHNICAL FIELD

The present disclosure relates to applying service function chains innetworks.

BACKGROUND

Service Function Chaining enables virtualized networking functions to beimplemented as part of a cloud network. A Service Function Chain definesan ordered list of a plurality of service functions (e.g., firewall,compression, intrusion detection/prevention, load balancing, etc.) thatmay be applied to packet flows in the network. A flow enters the networkthrough a classifier node that generates a Service Function Path forthat flow according to the Service Function Chain policy. The classifiernode encapsulates each packet of the flow with a Network Service Headerthat indicates the service functions to which the flow will besubjected, and the order the service functions will be applied.

Service Function Chaining and Network Service Headers provide ascalable, extensible, and standardized way of sharing metadata betweenboth network nodes and service nodes within a network topology. Thisallows for disparate nodes that require shared context, but do notcommunicate directly, to share that context via metadata within thepackets traversing the network or service topology.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a system block diagram showing a Service Function Chainnetwork environment with monitoring of the performance of servicefunctions, according to an example embodiment.

FIG. 2 is a simplified block diagram of a service function device withinthe Service Function Chain network environment, according to an exampleembodiment.

FIG. 3 is a simplified block diagram of a classifier network elementwithin the Service Function Chain network environment, according to anexample embodiment.

FIG. 4 is a ladder diagram that shows messages passed between peerservice function nodes when the performance of one of the servicefunctions is compromised, according to an example embodiment.

FIG. 5 is a ladder diagram that shows messages passed between nodes in aservice function chain when the performance of one of the servicefunctions is compromised, according to an example embodiment.

FIG. 6 is a flowchart showing the operations of a service function nodethat suffers from degradation in its ability to perform the servicefunction, according to an example embodiment.

FIG. 7 is a flowchart showing the operations of a node in a servicefunction path when another node is degraded in its ability to perform aservice function, according to an example embodiment.

DESCRIPTION OF EXAMPLE EMBODIMENTS Overview

At a service function node configured to perform at least one servicefunction on a data flow that follows a service function path,degradation in performing the service function is detected. The servicefunction node generates a status indicator for the degradation inperforming the service function and inserts the status indicator into apeer detection packet. The peer detection packet encapsulates an innerpacket with a header that indicates the service function path. Theservice function node forwards the peer detection packet to aneighboring service function node along the service function path.

Example Embodiments

Service Function Chaining provides both metadata of a data flow andsteers the flow to appropriate service functions. The Service FunctionChaining encapsulation carries information that identifies a ServiceFunction Path. The Service Function Path comprises an ordered list ofservice functions that act on the packets in the data flow. In oneexample, one or more service functions may be unavailable (e.g., thenetwork path is broken) or overloaded (e.g., due to processing othertraffic). To determine if the network path to the next service functionis available, a service function may use ping-like messages, whichoperate at a low level. In one example, a Generic Routing Encapsulation(GRE) tunnel may use a GRE keepalive message exchange.

The techniques described herein provide for carrying additionalinformation regarding the status of the service function beyond a merelink-level “ping” test. Network Service Headers, as defined by variousRequest for Comments published by the Internet Engineering Task Force(IETF) for example, are used to indicate the status of each servicefunction, and a service function that receives a packet with a NetworkService Header carrying this additional information may reactappropriately, e.g., using a different Service Function Path or adifferent service function node.

Referring now to FIG. 1, a simplified block diagram of a data flowsystem 100 between two endpoint devices is shown. A source endpoint 110sends a data flow to destination endpoint 120 through the ServiceFunction Chain system 130. Endpoints 110 and/or 120 may include, forexample, smart phones, tablets, laptop computers, desktop computers,virtual machine applications running in a datacenter, or other types ofcomputing devices. Service Function Chain system 130 comprises a serviceclassifier node 140, network devices (e.g., Service Function Forwarders)150, 160, and 170. Network device 150 forwards packets in data flows toservice functions 152 and 154. Network device 160 forwards packets indata flows to service function 162. Network device 170 forwards packetsin data flows to service functions 172 and 174.

In one example, all of the service function nodes attached to oneService Function Forwarder, such as service functions 152 and 154attached to network node 150, perform the same service function. TheService Function Forwarder may load balance performance of the servicefunction by sending packets to a plurality of instances of the servicefunction. Alternatively, the service function nodes attached to eachService Function Forwarder may provide different service functions. Inanother example, each Service Function Forwarder node handles all of theinstances of a given service function in a Service Function Path.Alternatively, a service function may be repeated at different ServiceFunction Forwarders, e.g., service function node 152 may perform thesame service function as service function node 162.

Service function 172 includes service function (SF) degradation logic180 to monitor the performance of the service function. Other servicefunctions in addition to the service function 172 may also includeservice function degradation logic to monitor their respectiveperformance. Service classifier 140 includes Service Function Pathdegradation logic 190 to determine the performance of the servicefunctions in a particular Service Function Path and handle anydegradation in performance. In one example, degradation in performanceof a service function may include a complete failure of a servicefunction node such that the service function cannot perform any tasks onany data flows. Alternatively, degradation in performance of the servicefunction may include processing the data flows with the service functionmore slowly than expected such that a bottleneck at the degraded servicefunction slows the data flow throughout the entire Service FunctionPath.

In the example shown in FIG. 1, the Service Function Chain system 130 isshown with one service classifier, three Service Function Forwarder(SFF) network nodes, and five service function nodes, but the techniquespresented herein may be applied to Service Function Chaining systemswith any number of SFF network nodes and any number of servicefunctions. Additional network elements, either inside the ServiceFunction Chain system 130 or outside of the system 130 may also beincluded to transmit the flows between source endpoint 110 anddestination endpoint 120. Additional service classifiers may also beincluded in the Service Function Chain system 130, e.g., to handlereturn data flows from the destination endpoint 120 to the sourceendpoint 110. In another example, one or more of the nodes in theService Function Chain system 130 may be physical devices or virtualmachines running in a data center.

Dead peer detection involves an exchange of low-level packets betweentwo nodes, i.e., peer nodes, to detect whether the nodes remain incommunication with each other. Peer nodes may include two servicefunction nodes that perform neighboring service functions in the ServiceFunction Path. The service classifier and the service function nodeperforming the first service function may also be peer nodes. In oneexample, peer nodes in a Service Function Path use GRE keepalivemessages for dead peer detection. Alternatively, peer nodes may use anInternet Security Association and Key Management Protocol (ISAKMP)message exchange of an R-U-THERE message and an R-U-THERE-ACK response.In general, the low-level packet exchange by peer nodes will be referredto hereinafter as peer detection messages, peer detection requests, andpeer detection responses.

If the service function node 172 is unable to perform its servicefunction(s) or is overloaded in capacity, then the service functiondegradation logic 180 will add metadata to the Network Service Header ina peer detection message. The metadata may include a status indicatorthat allows the service function node 172 to indicate its currentstatus. In one example, the status indicator may be similar to HypertextTransfer Protocol (HTTP) response codes, i.e., 1xx for informationalcodes, 2xx for success codes, 3xx for redirection codes, 4xx for clienterror codes, and 5xx for server error codes. Sub-codes within the codeclasses may provide further information describing the status of theservice function node 172. In another example, the Network ServiceHeader may be integrity protected and encrypted to ensure that thestatus indicator carried in the metadata of the Network Service Headeris not compromised.

The peer detection message is received by a neighboring peer node, suchas the previous service function node 162 in the Service Function Path.Additionally, Service Function Forwarder 170 and/or Service FunctionForwarder 160 may receive the peer detection message with the statusindicator. The Network Service Header may include additionalinformation, such as statistical information on the performance of theservice function node 172. The Service Function Forwarders may use thisstatistical information to make an informed load distribution decisionamong the instances of the same service function. Any node that receivesa status indicator that a service function node is not able to performadequately will ensure that existing flows are unaffected, especially ifthe service functions in the Service Function Path are stateful.Redirection to a new service function node or an alternative ServiceFunction path will typically only be relevant for subsequent flows.

In another example, the service function node 172 may insert the statusindicator into the Network Service Header metadata of a peer detectionresponse. Alternatively, the service function node 172 may send thestatus indicator in its own peer detection request, particularly if theservice function node 172 wants to immediately notify that it can nolonger service packets. This peer detection request may be sent multipletimes to handle packet loss and ensure that the status indicator isreceived by the peer node.

Referring now to FIG. 2, a simplified block diagram is shown of aservice function node 172 configured to perform a service function.Service function node 172 includes, among other possible components, aprocessor 210 to process instructions relevant to processing packets indata flow, and memory 220 to store a variety of data and softwareinstructions (e.g., service function logic 225, service functiondegradation logic 180, etc.) The service function node 172 furtherincludes a network interface unit 230 configured to communicate withother computing devices over a computer network.

Memory 220 may include read only memory (ROM), random access memory(RAM), magnetic disk storage media devices, optical storage mediadevices, flash memory devices, electrical, optical, or otherphysical/tangible (e.g., non-transitory) memory storage devices. Theprocessor 210 is, for example, a microprocessor or microcontroller thatexecutes instructions for implementing the processes described herein.Thus, in general, the memory 220 may comprise one or more tangible(non-transitory) computer readable storage media (e.g., a memory device)encoded with software comprising computer executable instructions andwhen the software is executed (e.g., by the processor 210) it isoperable to perform the operations described herein.

It is to be understood that the service function node 172 may be aphysical device or a virtual (software) device. In the latter case, theservice function node 172 is embodied as software running on a computernode (e.g., in a datacenter or other environment) through which trafficis directed and for which determinations are made as to how packets areto be routed into a Service Function Chain.

Referring now to FIG. 3, a simplified block diagram is shown of aclassifier network device 140 configured to perform the techniques of aclassifier node. Classifier 140 includes, among other possiblecomponents, a processor 310 to process instructions relevant toprocessing communication packets for a Service Function Chain system,and memory 320 to store a variety of data and software instructions(e.g., Classification logic 330, Service Function Path degradation logic190, communication packets, etc.). The classifier 140 also includes anetwork processor application specific integrated circuit (ASIC) 340 toprocess communication packets that flow through the classifier device140. Network processor ASIC 340 processes communication packets be sentto and received from ports 350, 351, 352, 353, 354, and 355. While onlysix ports are shown in this example, any number of ports may be includedin classifier device 140.

Memory 320 may include read only memory (ROM), random access memory(RAM), magnetic disk storage media devices, optical storage mediadevices, flash memory devices, electrical, optical, or otherphysical/tangible (e.g., non-transitory) memory storage devices. Theprocessor 310 is, for example, a microprocessor or microcontroller thatexecutes instructions for implementing the processes described herein.Thus, in general, the memory 320 may comprise one or more tangible(non-transitory) computer readable storage media (e.g., a memory device)encoded with software comprising computer executable instructions andwhen the software is executed (e.g., by the processor 310) it isoperable to perform the operations described herein.

It is to be understood that the classifier network device 140 may be aphysical device or a virtual (software) device. In the latter case, theclassifier network device 140 is embodied as software running on acompute node (e.g., in a datacenter or other environment) through whichtraffic is directed and for which determinations are made as to howpackets are to be routed into a Service Function Chain.

Referring now to FIG. 4, a ladder diagram is shown of peer servicefunction nodes 162 and 172 exchanging peer detection messages withstatus indicators. Service function node 162 initiates a peer detectionexchange with service function node 172 by sending peer detectionrequest message 410. The peer detection reply 415 may include a statusindicator which indicates that the service function node 172 issuccessfully performing the service function at the time that message415 is sent.

The performance of the service function in service function node 172starts to be degraded at 420. The degradation may be, for example, aslowdown in the processing of packets with the service function.Alternatively, the degradation may be a total inability of the servicefunction node 172 to perform the service function. In response to thenext peer detection request 430 from the peer service function node 162,the service function node 172 sends a peer detection reply 435 with astatus indicator. In one example, the status indicator is included inmetadata of the Network Service Header of the peer detection reply 435,and indicates the degradation in the performance of the service functionat service function node 172.

Referring now to FIG. 5, a ladder diagram of peer detection messagesexchanged between peers along an entire Service Function Path is shown.In this example, The Service Function Path includes service functions A,B, and C. Packets in this Service Function Path start at the classifier140 and proceed to service function A performed at service function node152. After service function node 152, the packets continue to servicefunction B performed at service function node 162 and service function Cperformed at service function node 172. After a service functiondegradation is detected, that information is propagated throughout theService Function Path to ensure that each node can take the mostappropriate action in resolving the degradation. Since the mode ofencapsulation of the peer detection messages may vary between peers, thestatus indicator may be propagated throughout the Service Function Pathusing different formats. In the example of FIG. 5, the status indicatoris converted from an R-U-THERE exchange to a GRE keepalive exchange.

In normal operation, the classifier 140 and the service function node152 are peer nodes that detect each other through a GRE peer detectionexchange 510. The service function node 152 and service function node162 are peer nodes that detect each other through GRE peer detectionexchange 512. The service function node 162 and service function node172 are peer nodes that detect each other through an R-U-THERE messageexchange 514. The peer detection exchanges 510 and 512 are in adifferent format than peer detection exchange 514, and are typicallyindependent exchanges of low level peer detection request and responsemessages. The peer detection exchanges 510, 512, and 514 may be repeatedat intervals to allow each node to detect neighboring nodes.

The performance of the service function C in service function node 172starts to be degraded at 520. The service function node 172 sends anR-U-THERE message 530 to the service function node 162 and includes astatus indicator in the metadata of the Network Service Header in theR-U-THERE message 530. The status indicator indicates that servicefunction C is degraded at service function node 172. The servicefunction node 162 responds with an R-U-THERE-ACK response message 535 tocomplete the peer detection exchange. In another example, the servicefunction node 162 may initiate the R-U-THERE peer detection exchangeinstead of service function node 172. In this case, the service functionnode 172 will include the status indicator in the R-U-THERE-ACK message.

The service function node 162 propagates the status information back upthe Service Function Path to ensure that the most appropriate action istaken by each node in the Service Function Path. In response to the nextGRE peer detection request 540 by the service function node 152, i.e.,the previous node in the Service Function Path, the service functionnode 162 inserts a status indicator into the metadata of the NetworkService Header of GRE peer detection reply message 545. The statusindicator indicates that the service function C is degraded at theservice function node 172. In another example, the service function node162 may not wait for the service function node 152 to initiate the GREkeepalive exchange and may send its own GRE keepalive message with thestatus indicator.

The service function node 152 propagates the status information up theService Function Path by sending a GRE peer detection request 550 to theservice classifier node 140. The GRE peer detection request 550 includesin a Network Service Header the status indicator that indicates thatservice function C is degraded at service function node 172. The serviceclassifier 140 completes the GRE peer detection exchange with replymessage 555. In another example, the service function node 152 may waitfor the service classifier 140 to initiate the GRE keepalive peerdetection exchange. In this case, the service function node 152 willinsert the status indicator into the GRE peer detection reply message.

While the description of FIG. 5 focuses on GRE and R-U-THERE (e.g.,Internet Protocol Security (IPSec)) peer detection encapsulationmechanisms, other modes of encapsulation (e.g., Virtual Extensible LocalArea Network—Generic Protocol Extension (VxLAN-gpe), Ethernet, etc.) maybe used to relay the status of a service function in the Network ServiceHeader. In the context of Cloud Web Security, the techniques presentedmay be used to relay serviceability of service functions. In one exampleof Cloud Web Security, GRE or IPSec is used to transport the NetworkService Header from a connector to the cloud network. The Cloud WebSecurity service may relay its status back to the connector. Theconnector may continue to tunnel into a specified Cloud Web Securitydata center as long as the Cloud Web Security service is functioning.The connector may switch to a suggested alternative data center if itreceives a redirection status indicator from the primary data center. Inone example, the address of the alternative data center may be includedin the redirection status from the primary data center. Alternatively,the connector may switch to a predetermined secondary data center if theCloud Web Security service returns an error status indicator.

Referring now to FIG. 6, a flowchart is shown for a process 600 by whicha service function node notifies a peer node of a degradation in theperformance of a service function. In step 610, the service functionnode detects degradation in a service function (e.g., a partial orcomplete inability to process packets in a timely manner) at the node.The service function node generates a status indicator that describesthe degradation in step 620. In step 630, the service function nodeinserts the status indicator into metadata of a Network Service Headerin a peer detection packet. The peer detection packet may be a GREkeepalive message or a response to a GRE keepalive message from a peernode. In step 640, the service function node forwards the peer detectionpacket with the status indicator to a neighboring service function node.The neighboring service function node, i.e., a peer node, may be theinitiator or the responder in a GRE keepalive exchange.

In one example, the peer detection packet encapsulates an inner packetincluding the Network Service Header. The Network Service Header willtypically be used to encapsulate a payload for the Service FunctionChaining system and includes an indication of the particular ServiceFunction Path for the payload.

Referring now to FIG. 7, a flowchart is shown for a process 700 by whicha peer node receives a status indicator of a degraded service functionand reacts to the status indicator appropriately. In step 710, a peernode receives a peer detection packet from a service function node. Instep 720, the peer node detects a status indicator indicating that theperformance of a service function at a service function node isdegraded. In one example, the service function node with degradedperformance may be the peer service function node from which the peerdetection packet was received. Alternatively, the service function nodewith degraded performance may be further down the Service Function Path.

If the peer node is not the service classifier for the Service FunctionPath, as determined in step 730, then the peer node propagates thestatus of the degraded service function to a previous node in theService Function Path, e.g., in another peer detection message, in step740. If the peer node is the service classifier, then the peernode/service classifier adjusts the Service Function Path in step 750.In one example, the service classifier may adjust the Service FunctionPath by directing subsequent packets in the data flow to a secondService Function Path that does not include degraded service functionnode.

In summary, the techniques presented herein provide for a mechanism toconvey the status of a service function using the Network Service Headerof a peer detection message. A service function node that receives aNetwork Service Header with this status information may then reactappropriately, e.g., by altering the Service Function Path, or bypicking an alternative service function node to provide the servicefunction. In this way, the liveliness of the service function nodes willbe detected. Additionally, the Network Service Header metadata mayconvey the service function node liveliness to the service classifier,which may change the Service Function Path. Further, the Network ServiceHeader metadata may convey the service function node liveliness to aService Function Forwarder, which may forward data to a differentinstance of the service function at a different service function node.In these examples, the status of a service function may be relayedwithin the data plane without any need for a separate control plane.

In one form, the techniques presented herein provide for acomputer-implemented method performed at a service function node in aService Function Path. At a network device or a computing deviceconfigured to perform at least one service function on a data flow thatfollows a service function path, the method comprises detectingdegradation in performing the service function. The method furthercomprises generating a status indicator for the degradation inperforming the service function and inserting the status indicator intoa peer detection packet. The peer detection packet encapsulates an innerpacket with a network service header that indicates the service functionpath. The computing device forwards the peer detection packet to aneighboring service function device along the service function path.

In another form, the techniques presented herein provide for anapparatus comprising a network interface unit and a processor. Thenetwork interface unit is configured to communicate with a plurality of(physical or virtual) service function devices in a service functionpath. The processor is configured to perform at least one servicefunction on a data flow that follows the service function path. Theprocessor is configured to detect degradation in performing the servicefunction and generate a status indicator for the degradation inperforming the service function. The processor is further configured toinsert the status indicator into a peer detection packet thatencapsulates an inner packet. The inner packet includes a networkservice header that indicates the service function path. The processoris configured to cause the network interface unit to forward the peerdetection packet to a neighboring service function along the servicefunction path.

In yet another form, the techniques presented herein provide for acomputer-implemented method performed at a peer node in a ServiceFunction Path. The method comprises receiving a peer detection packetfrom a (physical or virtual) service function device in the ServiceFunction Path. The peer detection packet comprises an inner packet witha network service header. The method further comprises detecting astatus indicator in the network service header. The status indicatorindicates degradation in performing a service function at the servicefunction device. The method also comprises adjusting the servicefunction path to compensate for the degradation in performing theservice function at the service function device.

In still another form, a non-transitory computer readable storage mediais provided that is encoded with instructions that, when executed by aprocessor, cause the processor to perform any of the methods describedand shown herein.

The above description is intended by way of example only. Variousmodifications and structural changes may be made therein withoutdeparting from the scope of the concepts described herein and within thescope and range of equivalents of the claims.

What is claimed is:
 1. A method comprising: at a computing deviceconfigured to perform at least one service function on a data flow thatfollows a service function path, detecting a degradation in performingthe service function; generating a status indicator for the degradationin performing the service function; inserting the status indicator intoa peer detection packet, the peer detection packet encapsulating aninner packet with a header that indicates the service function path; andforwarding the peer detection packet to a neighboring service functiondevice along the service function path.
 2. The method of claim 1,wherein the status indicator is inserted as metadata in a networkservice header of the inner packet of the peer detection packet.
 3. Themethod of claim 1, further comprising inserting service functionstatistical information into the network service header, wherein theservice function statistical information describes the performance levelof the computing device in performing the at least one service function.4. The method of claim 1, wherein the status indicator indicates one ormore of a success status, a redirection status, or a server errorstatus.
 5. The method of claim 1, further comprising: receiving a peerdetection request packet from the neighboring service function device;and replying to the peer detection request packet with the peerdetection packet including the status code.
 6. The method of claim 1,wherein the peer detection packet comprises a Generic RoutingEncapsulation (GRE) keepalive notification packet, a GRE responsepacket, an Internet Security Association and Key Management Protocol(ISAKMP) R-U-THERE message, or an ISAKMP R-U-THERE-ACK message.
 7. Anapparatus comprising: a network interface unit configured to communicatewith a plurality of service function devices in a service function path;and a processor configured to: perform at least one service function ona data flow that follows the service function path; detect a degradationin performing the service function; generate a status indicator for thedegradation in performing the service function; insert the statusindicator into a peer detection packet, the peer detection packetencapsulating an inner packet with a header that indicates the servicefunction path; and cause the network interface unit to forward the peerdetection packet to a neighboring service function device along theservice function path.
 8. The apparatus of claim 7, wherein theprocessor is configured to insert the status indicator as metadata in anetwork service header of the inner packet of the peer detection packet.9. The apparatus of claim 7, wherein the status indicator indicates oneor more of a success status, a redirection status, or a server errorstatus.
 10. The apparatus of claim 7, wherein the processor is furtherconfigured to: receive a peer detection request packet, via the networkinterface unit, from the neighboring service function device; and causethe network interface unit to reply to the peer detection request packetwith the peer detection packet including the status indicator.
 11. Theapparatus of claim 7, wherein the peer detection packet comprises aGeneric Routing Encapsulation (GRE) keepalive notification packet, a GREresponse packet, an Internet Security Association and Key ManagementProtocol (ISAKMP) R-U-THERE message, or an ISAKMP R-U-THERE-ACK message.12. A method comprising: receiving a peer detection packet from aservice function device in a service function path, the peer detectionpacket comprising an inner packet with a header; detecting an statusindicator in the header, the status indicator indicating a degradationin performing a service function at the service function device; andadjusting the service function path to compensate for the degradation inperforming the service function at the service function device.
 13. Themethod of claim 12, wherein the status indicator is detected as metadatain a network service header.
 14. The method of claim 12, wherein thestatus indicator indicates one or more of a success status, aredirection status, or a server error status.
 15. The method of claim14, further comprising: responsive to the status indicator indicating aredirection status, adjusting the service function path by redirectingfuture data flows to an alternative data center as indicated in theredirection status; and responsive to the status indicator indicating aserver error status, adjusting the service function path by redirectingthe future data flows to a predetermined secondary data center.
 16. Themethod of claim 12, wherein adjusting the service function pathcomprises sending a new peer detection packet to a previous device inthe service function path.
 17. The method of claim 16, wherein theprevious device is a previous service function device, a servicefunction classifier device, or service function forwarder device. 18.The method of claim 12, wherein adjusting the service function pathcomprises classifying a data flow into a new service function path thatavoids the service function device.
 19. The method of claim 12, whereinadjusting the service function path comprises providing the servicefunction from a different service function device.
 20. The method ofclaim 19, further comprising determining the different service functiondevice based on service function statistical information in the header.